Disaster rehearsal for a storage area network utilizing a replication appliance is challenging to perform adequately. Stopping replication between a primary storage area network and a secondary storage area network so that no data writes are replicated across to the secondary storage area network is one current way to test the secondary storage area network (SAN) as it would perform if the primary storage area network were to go down. This approach requires replication to be stopped between the primary storage area network and the secondary SAN so that a secondary host can utilize Logical Unit Numbers (LUNs) associated with the secondary SAN. Disaster rehearsal testing requires not only reading data but also writing data to ensure that full functionality is available in case the primary SAN fails. Resynchronization of the two SANs in this method requires a full resynchronization which requires sending all data from the primary SAN to the secondary SAN. This can have a significant impact on the performance and availability of both SANs, and is a time consuming, expensive and inefficient process. Additionally, if the secondary SAN is written to during testing, there is not a clean copy of production data in the event that the primary SAN fails.
Another approach involves creating a snapshot of the data on the secondary SAN and exporting the snapshot. The replication appliance then exports virtual LUNS pointing to the snapshot for the secondary host. The disaster rehearsal then uses the virtual LUNS and the snapshot data to test. During this testing all input/output (I/O) goes through the replication appliance. Thus, the direct path from the secondary host to secondary LUNs and the corresponding data is never tested. This is significant because this is the path and the data that would be used if the primary SAN did fail. Furthermore, all input/output during this testing going through the replication appliance adds network traffic that the replication appliance has to handle. Additionally, it is not a true test of the components of the secondary SAN.
Still another approach requires pausing replication and exporting a full copy of the secondary SAN data. The replication appliance then exports virtual LUNs pointing to the exported copy for the secondary host to utilize. The secondary host is required once again to route all input and output through the replication appliance during disaster rehearsal testing against the exported copy. Again, the direct path from the secondary host to secondary LUNs and the corresponding data is not tested. As in the previous approach, network traffic that the replication appliance has to handle is greatly increased and it is not a true test of the components of the secondary SAN.
In view of the foregoing, it would be desirable to provide a technique for disaster rehearsal testing in storage area network (SAN) utilizing a replication appliance which overcomes the above-described inadequacies and shortcomings.